The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art, merely by inclusion in this section.
The creation of software applications is becoming more and more complex. For example, hundreds of software engineers spanning the globe may simultaneously work on the production of a single software application, or may simultaneously work on various related software applications. Additionally, the work on the software application may continue throughout the day and night. For example, engineers in California may work on a certain portion of a software application during a day. At the end of the day, the application may then be e-mailed to another team of engineers working in another country, such as India or Japan, so that another other team of software engineers may continue to work on the application. In this manner, the creation of the software product may continue around the clock.
Additionally, software applications are often created incrementally, and must be moved from one environment to another environment. For example, a software application may need to be moved from a production environment to a testing environment. However, when engineers are scattered across the globe, and production continues around the clock, various challenges arise in maintaining integrity and coalescence among single and multiple applications. For example, metadata may be changed by an engineer working on an application in California, but, if an engineer in India or another country is working on the same application or a related application, metadata in a portal object that is sent from the engineer in California to the engineer abroad may be corrupted or inconsistent.
During software production processes, various installations (e.g., portals) may be involved. In each of the installations, portal objects are created. Portal objects may include application components and/or design elements. The application components used by an application may include, for example, Forms, Reports, Charts, etc. The design elements used by an application may include, for example, Pages (Deciding on the Layout and Regions), Styles, Templates, etc. Portal objects may be migrated for various purposes, such as, for example, moving a portal object to another installation so that another software engineer may alter or test the portal object in an incremental software development and testing environment.
When a portal object is created, metadata concerning the portal object is often stored in a portal table. An installation may have as many as 500 or more tables that comprise the architecture of the software application. The portal tables are used to hold metadata of different kinds of objects. There is often a need to migrate such portal objects from one installation of portal to another installation of portal. For example, if 25 distinct portal objects, each of a different type, need to be migrated to a different portal instance, then a subset of the more than 500 tables, which a user believes may encapsulate the metadata of all twenty-five of the different objects, may be imported or exported. However, complications arise because during the migration, the metadata of objects that already exist on the target portal may be corrupted during the import.
One prior approach to maintaining consistency across applications is versioning. Different versions of the application, including a master version of the application, were maintained. When an engineer completed his or her version of the application, it was copied into the master version. This approach is cumbersome and does not always result in consistent data across applications.
Most of the previously existing approaches for migrating portal objects employ hard-coded and ad-hoc logic to copy metadata from a source portal to target portal. The fact that existing solutions must be hard-coded and prepared in an ad-hoc manner does not allow parallel developments to occur in an efficient fashion. Moreover, as mentioned above, in existing approaches for migrating portal objects, metadata is often corrupted. Hence, there is a need for a framework to be designed in such tools to facilitate the migration of portal objects in a systematic way from a source installation to a target installation.